snapshot: Use a better placeholder

An empty container has the same effect as transparency
with the cairo renderer, but creates black with Vulkan.
To avoid this, explicitly use a transparent color node.

This fixes the css blendmode example in gtk4-demo with
the Vulkan renderer.

Regenerate blendmodes reftest

Fix blendmode shader

My reading of the spec formulas was imperfect.

Revise coordinate handling for blend nodes

This is the same change that was applied to cross-fade
nodes.

Stop using gsk_cairo_node_new_for_surface

Best to avoid handling the surface ourselves.

Add another blendmodes reftest

This tests all blendmodes. Again, the Vulkan renderer fails.

Revise the coordinate handling one more time

This makes the new reftests pass and hopefully does not
break other things.

Dialog: Clarify that response ID 0 is not reserved

I only got so far in math, but it looks to me like zero isn’t positive.
We don’t reserve it, so be clear about that.

MenuButton: Document the correct no-direction icon

Document open-menu-symbolic, which we use, not view-context-menu, which
does not exist.

Add a cross-fade node ref test

The Vulkan renderer doesn't pass this one either, currently.

Add a blendmode node reftest

The Vulkan renderer doesn't pass this, currently.

Fix application window snapshot differently

As Timm Baedert pointed out, the previous fix made the
menubar go on top of popovers, which is just wrong. Instead,
make gtk_window_snapshot handle all direct children of the
window, taking care to stack popovers correctly.

Expand the repeat node test

Still not exhaustive, but enough to find some issues.

Add a repeat node test

Add a basic cairo node test

Allow backend-specific reference images

This is not ideal, but lets us deal with differences for now.

vulkan: Fix cross-fade node coordinates

This is the same fix as was just committed for blendmode nodes.

vulkan: Fix blendmode coordinate handling

We were node handling coordinates correctly when dealing
with differently sized child nodes in a blendmode node.
This was showing up in the gtk4-demo css blendmode example,
for blendmodes other than normal.

vulkan: Fix repeat node coordinates

We were not treating non-trivial child bounds right at all.
This was visible in the css blendmode cmyk example in gtk4-demo,
for the normal blendmode.

inspector: Show child bounds for repeat nodes

The more information, the better.

Create tests for cairo node

https://bugzilla.gnome.org/show_bug.cgi?id=788534

gsk: Move gsk_cairo_node_new_for_surface into public API

https://bugzilla.gnome.org/show_bug.cgi?id=788534

gsk: Fix serialization of cairo node

https://bugzilla.gnome.org/show_bug.cgi?id=788534

testmenubutton: Fix inverted keynav in the GtkMenu

GtkMenu’s own keynav code, which actually bothers to account for the
layout of items, only happens if columns > 1. So, adding items to 1
column using a reverse loop meant they were placed in the Menu’s list of
children in that order, and because we only have 1 column, Menu passes
keynav up to MenuShell, which doesn’t adjust for the items’ positions.

‘Fix’ that here by adding items in the same order they’ll have when laid
out in the Menu, so keynav does what you’d expect, not the opposite. For
that, it’s simpler just to use gtk_container_add().

Let’s presume users are using add(), attach() with a non-inverted loop,
or attach() with arguments that create 2+ columns and so GtkMenu keynav.

snapshot: Set blend mode directly after pushing state

This is important since _push_state returns a pointer into a GArray
which could be invalidated and point to garbage after the subsequent
push_state call.

snapshot: Fix blend mode handling

We were getting out states confused and were always creating
a blend mode node with mode NORMAL.

gtk4-demo: fix a typo

The blend mode is called saturation, not saturate.

Adwaita: theme the shortcuts window search results

Add some margins, and, since we can, also move the spacing here.

Shortcuts window: Make search results themable

Add a style class to the box containing search results,
so we can apply style here.

application window: Make menubar appear

This needed to be ported to snapshot, still.

Adwaita: theme shortcuts windows a bit

Add some space around the content.

shortcuts: Add css names to some widgets

This will let us put some styling in place for these.

gtk4-demo: Fix the scrollbar popup menu example

A scrollbar is not a range anymore, so the callback
needs some adjustments (!).

scrollbar: keep populate-popup signal working

This is used for example in the source tab of gtk4-demo.
It broke because GtkScrollbar no longer is a GtkRange,
but rather has one. So we need to forward the signal.

notebook: Don't steal right-clicks from content

We only want to pop up the context menu in the tab strip.

Adwaita: Fix scrollbar theming a bit

Reinstate the fine-tune mode scrollbars.

scrollbar: Correct css docs

The .fine-tune class appears on the range node.

Drop the env var for scrolling control

This was never meant to be an official api, but rather
a transition help. Time to drop it for GTK+ 4.

textview: Fix memory handling

When cleaning up the text appearance struct, we forgot
to add the new strikethrough_rgba member to the copy
function.

printing: Fix page drawing

We were drawing frames around our drawing areas.

printing: Some fixes to the print dialog

Hide widgets that are meant to be hidden initially, and use
the right spin button apis.

button: Fix label alignment in checks and radios

Yes, this is ugly, but the alternative is broken ui.

gtk-demo: Deal with big images

We don't want to grow our window to huge size just because
there is a big source image.

gtk-demo: Add a new overlay demo

Replace the not very impressive transparent demo with
the blur-behind example.

gtk-demo: Fix the overlay demo

We must make the label and the entry separate overlays, or
the entry will also be clickthru.

gtk-demo: Fix up the drawingarea example

This was not working anymore.

gtk-demo: Make the color chooser example non-resizable

No need for it.

HC: Avoid inflated titlebar separator in GEdit etc

It was selecting paned separator, which means any separator at any level
of descent within a paned, including the toplevel container in GEdit.

We need to be more specific and only select the relevant separator that
is the direct child of the paned. This is what Adwaita does.

https://bugzilla.gnome.org/show_bug.cgi?id=788573

TreeViewCol: Fix SEGV on remove/add, + memory leak

Nulling priv->button in _unset_tree_view() is asymmetrical: we create
it via init(), not _set_tree_view(), so we shouldn’t null in the latter.

Worse, doing so manifests in criticals + a SEGV easily with basic use of
testtreecolumns, removing the TVC from a TV then trying to add it to one

Finally, the wrong null-out meant dispose() failed to unref the button,
so it leaked.

https://bugzilla.gnome.org/show_bug.cgi?id=728452
https://bugzilla.gnome.org/show_bug.cgi?id=788614

TreeViewCol: Don’t try to disconnect null treeview

https://bugzilla.gnome.org/show_bug.cgi?id=788614

Revert "treeviewcolumn: Don't leak button"

This reverts commit 2c28c627c1527d4ee2dfc4d3805f7afc482049e2.

See following commits: the real problem is setting priv->button to NULL
soon after this, so this just makes that wrong decision look more right.

https://bugzilla.gnome.org/show_bug.cgi?id=788614

iconbrowser: Don’t repeat folder-download-symbolic

It was in both [general] with a description and [other] with none.
Leave it in [other] with the other folder- icons, + the description.

bonus: this makes all of [general] fit in our default window size!

FileChooserButton: Avoid unref()ing a null model

gtk-demo: Fix the assistant demo

The progress bar was no longer expanding as intended,
due to the demise of GtkBox::expand.

settings: Don't assert in notify

We can legitimately hit the default case in this switch,
so don't assert that we don't.

gskrenderer: Make the window property not construct

We never set this, since it is assigned as a side-effect
of realizing the renderer. Make this a plain readonly property.

vulkan: Add some missing cases to switch

build: Enable -Wswitch-enum and -Wswitch-default

This patch makes that work using 1 of 2 options:

1. Add all missing enums to the switch statement
  or
2. Cast the switch argument to a uint to avoid having to do that (mostly
   for GdkEventType).

I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.

The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.

build: Turn on more warning flags

-Wshadow these days does not overwarn anymore like it did in gcc 4.
There are no warnings inside gtk, so better enable it to keep it that
way.

-Wuninitialized also has no positives, so I'm gonna turn it on just
because.

gtk-demo: Keep treeviews expanding

This is fallout from GtkBox::expand child property going away.

gtktreeview: Transform cell area to widget coordinates

GtkCellArea uses event coordinates (thus in treeview relative
coordinates), but calculations used to happen in bin window coords.
We can just offset the cell area by the bin window, fixes cell
renderer activation and edition.

treeviewcolumn: Don't swallow motion/crossing events

If the column is not clickable, it may make some sense to stop
event propagation here for button events. However motion events
should be left alone.

Fixes treeview column resize pointer cursors, since that's
implemented up the bubbling phase in the treeview.

treeview: Transform motion event coords to "bin window" coords

The operations rely there on bin window relative coordinates, but we
are receiving GtkTreeView relative coordinates there. Fixes clicking
on treeview expanders, which was offset by visible headers.

modelbutton: set_relative_to(NULL) the popover in dispose

We do set_relative_to(menu_button) when creating it so we should do this
here (or nothing).

treeviewcolumn: Don't leak button

We g_object_ref_sink the button in _create_button, so we need to unref
it ourselves.

filechooserbutton: Don't leak priv->model

applicationwindw: Don't leak show-help-overlay action

widget-factory: Don't leak GPropertyAction instances

build: Don't turn off critical warnings

-Wint-conversion is important because it checks casts from ints to
pointers.

-Wdiscarded-qualifiers is important to catch cases where we don't
strings when we should.

gtk-demo: Remove old build file

The includes are now generated with a Python script, so remvoe the old
perl script.

build: Remove old Makefile.inc files

They seem to have been forgotten in the meson transition

Update Polish translation

Some updates

Widget: make sure windowed widgets have a 1×1 min size

widget: Allow 0×0 allocations

Don't MAX the allocations with 1 anymore.

searchbar: Remove superfluous padding

So it's not 6px high when the child revealer is concealed.

box: Drop priv pointer

image: Remove mention on gdk-pixbuf-csource

gdk-pixbuf-csource as well as gdk_pixbuf_new_from_inline are deprecated.
Mention GResource instead.

HC: Add border/hilight when hovering flat buttons

The border and icon highlight are useful feedback that was defeated by
CSS precedence. It worked for .titlebuttons due to their implementation,
but the same was not true for custom .flat buttons. This makes it so.

https://bugzilla.gnome.org/show_bug.cgi?id=788580

HC: Flat titlebuttons became non-flat in backdrop

When the window was backdropped, they suddenly regained their border.
This was clearly not intentional or of any practical use to anyone.

Shuffle around some selectors so that the backdrop ones do not override
the flat ones and make the borders magically reappear when backdropped.

Note that, whereas standard titlebuttons get the border on :hover, other
.flat buttons in the headerbar do not. That should probably be fixed too

https://bugzilla.gnome.org/show_bug.cgi?id=788580

HighContrastInverse: Make window borders visible

They were hard-coded to a transparent black, but that is our bg colour
in HC Inverse, so windows stacked on top of each other or a dark
background blended together into a mush.

Fix this by making the $_wm_border* colours relative to the fg colour,
so that HighContrastInverse gets borders that are transparentised white.

https://bugzilla.gnome.org/show_bug.cgi?id=788575

HC: Fix MessageDialog’s rounded bottom borders

A missing decoration selector meant that we got a solid black background
behind the rounded corners of the dialog.

Copy the equivalent code from Adwaita, including nicely rounding the
focus outline too (& sorry, but this needs more newlines to be readable)

HighContrast: Fix titlebar containing >1 headerbar

by migrating the relevant code from Adwaita, to dodge unwanted doubling
up of the bottom border and such.

https://bugzilla.gnome.org/show_bug.cgi?id=769877

HighContrast: set min-height for headerbars

https://bugzilla.gnome.org/show_bug.cgi?id=784562

HC: Copy working tooltip code from Adwaita & tweak

There were various problems, like only selecting on .tooltip and not the
widget node tooltip, not being specific enough for tooltip.csd, etc. So,
specific theming was absent, and default popup window styles got applied

This commit copies in the better working tooltip CSS from Adwaita, but
applies a couple of changes to make it work better in the HC themes:
 • Reduce the transparency of the tooltip, so we achieve higher contrast
 • Drop the black text-shadow, as it is not useful on this more black bg

Note: we may then need to re-add some of this to the .tooltip class. But
it is unclear what needs done there. While Adwaita is not doing it, we
are better not to confuse by keeping it in HC only; we should try to be
as close as possible, to make it easier for HC to keep up with Adwaita.

https://bugzilla.gnome.org/show_bug.cgi?id=769879

HC: Give tooltips a border for contrast on Inverse

https://bugzilla.gnome.org/show_bug.cgi?id=769879

HighContrast: Actually style tooltips...

We need to select on the widget itself too, not just other things with
the .tooltip class.

https://bugzilla.gnome.org/show_bug.cgi?id=769879

[l10n] Updated Catalan (Valencian) translation

switch: Fix int/double comparison

We get a double coordinate.

scrolledwindow: Make sure gtk_get_current_event_state returned a state

Technically correct and pleases Coverity.

appchooserdialog: Remove unused macro

combobox: Remove unneeded queue_resize call

The remove/add/set_parent/unparent calls in there already do the
necessary work.

HighContrast: Correctly select window decoration

We need

    .window-classes decoration

but within the decoration parent selector, we were doing
&.window-classes, which gave us

    decoration.window classes

We need to fix this by selecting on .window-classes &

https://bugzilla.gnome.org/show_bug.cgi?id=788496

wayland: fix a typo

This was noticed in the gtk3 backport of these changes.

updateiconcache: Avoid confusing loop construct

n_attach_points is the result of g_strv_length(): the index at which the
string vector ends in NULL. So by definition, when i == n_attach_points,
string[i] == NULL, and there is no need to check for the latter. The
fact that we did appears to confuse static analysers, as the dereference
and index check were inverted from what would normally be safe. We could
reverse them, but we may as well just remove the unnecessary NULL check.

https://bugzilla.gnome.org/show_bug.cgi?id=788458

Enter submenus when activating their parent item

This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).

This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area.  There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.

https://bugzilla.gnome.org/show_bug.cgi?id=778811

-wayland: Safeguard against NULL gtk_surface1

There is no guarantee that the gtk_surface won't be NULL,
and Wayland API does not safeguard against NULL, so we have
to do that ourselves here.

We were also mistakenly cheking for the surface version off
by one, fix that too by checking if the surface version is
equal or greater.

TreeMenu: Remove accidentally duplicated doc lines

Not that it actually matters, as this is not public anymore, but this
was done accidentally. Also, sync a property description to ComboBox.

testcombo: Test grid :row- and :column-span-column

Ditch two items that were white and so weren’t visible on our standard
theme anyway, and use the new space to test extra grid-mode properties.

Note that if we do this then, as before, we set the ListStore on the
ComboBox before appending to it, that produced runtime warnings like:

Gtk-CRITICAL **: gtk_menu_attach: assertion 'left_attach < right_attach' failed

I didn’t look into that yet, but it may indicate that attaching items
vs. recognising their spans don’t occur in the correct order. For the
purposes of testing this, I just create the CB after filling its model.

ComboBox|TreeMenu: Slightly clarify wrap-width doc